In today's information age, various electronic systems maintain a large amount of information regarding individuals that should be kept in confidence (where such information is generally referred to herein as “restricted data items”). Government institutions administer many such electronic systems, while the private sector (such as various financial institutions) administers many other such electronic systems. The restricted data items can include information that identifies the individuals, such as the individuals' names, telephone numbers, residential addresses, Email addresses, and so forth. The restricted data items can also include information regarding the individuals' financial assets (such as account numbers, income, etc.), their financial transactions, their various debts, their subscriptions, their medical histories, their insurance records, and so forth. It is paramount that the electronic systems protect the privacy of all restricted data items, as the release of such information to unauthorized parties can have negative consequences to the individuals. Identity theft is just one concern regarding the inappropriate release of restricted data items.
At the same time, various parties also have a legitimate need to gain access to these electronic systems. In one case, a tester may wish to test the electronic systems to ensure that the systems are working properly. For instance, before deploying updated functionality, a tester may want to test this functionality in a lab environment before deploying the functionality in a production environment. (As used in the art, the term “production environment” refers to the infrastructure used to deliver services to clients in the normal course of the environment's day-to-day activities. A “lab environment” refers to infrastructure specifically set up to test code functionality. The lab environment is preferably designed to mimic the production environment; for instance, it is common to construct the lab environment so that it is a scaled down version of the production environment.) In another application, a tester may wish to perform forecasting-type testing on an electronic system to determine how it will behave in the future, for example, in response to higher loads than it currently handles.
In another application, an analyst may wish to investigate the data maintained by the electronic systems for various purposes. For instance, a government analyst may wish to examine databases maintained by a government organization to determine economic trends, population-related trends, and so forth. A private sector analyst may wish to examine databases to determine marketing trends, cross-selling and up-selling opportunities, and so forth.
The administrators of electronic systems often cannot provide unrestricted access to their systems to accommodate the above needs. This is because the administrators are often under legal and/or contractual obligations to maintain the secrecy of the restricted data items. For this reason, administrators must look to alternative strategies for allowing various legitimate parties to interact with their systems.
In one such alternative approach, the administrators can generate a mock electronic system. The entire mock system is synthesized so that it resembles the original electronic system deployed in the production environment in some respects, but the mock system otherwise omits the restricted data items or provides “fake” restricted items in the place of actual restricted data items. The administrators can then allow outside parties to interact with the mock system by performing tests on the mock system and by analyzing the data stored by the mock system. The expectation behind this technique is that the mock system will have characteristics that statistically track the production system, so that a user's interaction with the mock system will serve as a meaningful “surrogate” for the user's precluded interaction with the actual production system. For example, there is an expectation that, if a series of tests performed on the mock system's database yields error-free results, then the production system will not experience problems when it is deployed.
However, the above-described expectations may not always hold up. As appreciated by the present inventors, production systems may enter unexpected states for reasons that are not immediately fully understood. Because these states are not anticipated, this also means that the synthesized mock system may not duplicate these states (because the mock system has not been designed to account for these states). This, in turn, means that the tests performed on the mock system may not account for the complete behavior of the actual production systems. This is a problem of significant weight, as the consequences of leaking personal information due to an unpredicted malfunction in the production system can be dire.
There is accordingly an exemplary need for more efficient and effective techniques for allowing various parties to interact with an electronic system which stores restricted data items, without revealing the restricted data items to those parties.